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Abstract — This paper deals with the study of Real-Time Tasks for Embedded Control S^tfj^a^ollowing 
component-based technology. A real-time task is assumed to be a set of componeftj/j^aving some 
properties independently from any real-time operating system. We apply the Pric^t^^mling Protocol 
(PCP) as a method to ensure the scheduling between periodic tasks with precedenclLirm mutual exclusion 
constraints. We simulate the scheduling of Real-time tasks with PCP through th^rwgSar tool. 
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I. Introduction 




Nowadays, the time to market the embedded systems is becomin^Wrrer and the cost of development is 
being cheaper. In order to realize this goal (i.e. reducing time dj4f%K&T), the designers of embedded system 
propose to reuse the already developped software components, ^ne main benefits of component are: (i) 
the separation of concerns which means that each component c#n be defined alone after that all the system 
can be reproduced; (ii) the modification of compooi^^J^ very simple (such as modification of data, 
algorithm, connection, ...); (iii) the adaptation of ccj^gOTnerit to any modification; (iv) there use of 

component (it is not specific for only one applicatiorf^^^ 

However, there are few kinds of component-bas^ technologies (such as Koala [i], PBO [2], PECOS [3], ...) 
used in the development of embedded corrfII|l system due to extra-functional properties to be verified (for 
example quality of service, timeliness, Anyway, each component-based technology has its benefits 

and its drawbacks. 

Although component technolo^leo^al successfully with functional attributes, they provide no support for 
managing extra-functional moperoes of systems (such as synchronization, memory optimization, power 
consumption, and temporafarWibutes) that cannot be encapsulated in one component with well-defined 
interfaces as they crosst^SuT^tructure of the overall system. To do so, we define at the operational level 
some sequential prapgf^Ainits called real-time tasks. Thus, we define a real-time task as a set of 
components havirmw^rj^ real-time constraints. We characterize a task by a set of properties independently 
from any Real Tim^ifcperating System (RTOS). 

We study i^An^Kular the scheduling of tasks through a Real Time Operating System. We apply the priority 
ceiling ^jrol(|^)l proposed by [5] to avoid the problem of priority inversion as well as the deadlock between 
the ^n^rVpt tasks. The priority ceiling protocol supposes that each semaphore is assigned a priority ceiling 
qual to the highest priority task using this semaphore. Any task is only allowed to enter its critical 
if its assigned priority is higher than the priority ceilings of all semaphores currently locked 
ther tasks. The contributions of this research work have been applied to the benchmarking production 
ystem : FESTO system (used as running example) allowing us to validate our results. 




The Section 2 presents the benchmark production system (FESTO system). We define in Section 3 the 
scheduling with the Priority Ceiling Protocol. The Section 4 treats the simulation of real-time tasks with the 
Cheddar tool. Finally, we conclude in the last section. 
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II. Benchmark Production System 



We present the Benchmark Production System (Detailed descriptions are available in the website: 
http://aut.informatik.uni-halle.de) : FESTO available in the research laboratory at the Martin Luther 
University in Germany. The FESTO Benchmark Production System is a well-documented demonstrator used 
by many universities for research and education purposes, and it is used as a running example in the context 
of this paper. FESTO is composed of three units: Distribution, Test and Processing units (Figure i). Th 
Distribution unit is composed of a pneumatic feeder and a converter to forward cylindrical work pieces fr A 
a stack to the testing unit which is composed of the detector, the tester and the elevator. This unit per 
checks on work pieces for height, material type and color. Work pieces that successfully pass this c 
forwarded to the rotating disk of the Processing unit, where the drilling of the work piece is performed 



assume in this research work two drilling machines Drill_machinei and Drill_machine2 to 
result of the drilling operation is next checked by the checking machine and the work piec 
another mechanical unit. 






£s. The 
arded to 



How to schedule pe 
as important as ho 
the priority-driV| 
solution can 



III. 

d< 




Vjs)* Scheduling With Priority Ceiling Protocol 

^^^ks with precedence and mutual exclusion constraints is considered 

present a task in a general real-time operating system. In our context, we choose 



mptive scheduling used in the most real-time operating systems. The semaphore 
the problem of priority inversion which consists that a high priority task can be 




blocked p\JL^3rer priority task. To avoid such problem, we propose to apply the priority inheritance 
protoco^pi|ra&sed by (Sha, 1990). 

ity inheritance protocol can be used to schedule a set of periodic tasks having exclusive access to 
resources protected by semaphores. To do so, each semaphore is assigned a priority ceiling which 

[rual to the highest priority task using this semaphore. A task T. is allowed to enter its critical section 

only if its assigned priority is higher than the priority ceilings of all semaphores currently locked by tasks 

other thanT, . 



protoco^ 
Tl^TO^ri 



Schedulability test for the priority ceiling protocol: a set of n periodic tasks using the priority ceiling 
protocol can be scheduled by the rate-monotonic algorithm if the following inequalities hold, 
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V i, i < i < n, Q/Tx + C 2 /T 2 + ... + Q/Ti + BJT, < i( 2 l/i -i) 

where Bi denotes the worst-case blocking time of a task T. by lower priority tasks. 



Running Example. In the FESTO Benchmark Production System, we consider three tasks Ri (a 
reconfiguration task), Si and S2 (service tasks) having as priority pi, p2 and p3 such that pi> pi> p^. 



The sequence of processing steps for each task is as denned in the section previous paragraph whereat 
(resp. R) denotes the service (resp. reconfiguration) semaphore: ^ 
Ri = { ... P(R) execute reconfiguration V(R) ... } 

51 = { ... P(S) ... P(R) ... V(S) execute service P(S) ... V(R) ... V(S) ... } 

52 = { ... P(S) ... P(R) ... V(S) execute service P(S) ... V(R) ... V(S) ... } 



Therefore, the priority ceiling of the semaphore R is equal to the task Ri (because the^r^ 
by the tasks Ri, Si and S2 and we know that the task Ri is the highest priority) and fh£pHpri 
semaphore 5 is equal to the task Si (because the semaphore 5 is used by th 
priority task of Si is higher). 




^^noi 

p^prity ceiling of the 



Lore R is used 



?d at 



Si and S2 and the 
nt t3. We suppose also that 



We suppose that the task S2 is running when the task Si is created 
the task Ri is created at the instant t$. w m 

In the Figure 2, a line in a high level indicates that the task is exec/Siy^t line in a low level indicates that 
the the task is blocked or preempted by another task. 

The following Table 2 explains more in details the exampl 



Event 



to 



ti 



t2 



t3 



t4 



S2 begins execution. 




TABLE I. The event and its coi^lpoTTding action in the Figure 2 



Action 



S2 locks S. The task S2 



The task Si is create 



The task Si fai 
S. The task^2 i 



The task 
preem 







s the priority of S. 



has more priority than S2, it begins its execution. 



tc ^ as its priority is not higher than the priority ceiling of the locked 
es the execution with the inherited priority of S. 



ks R. The task S2 inherits the priority of R. The task Ri is created and 
execution of S2 as it has the highest priority). 



fails to lock R as its priority is not higher than the priority ceiling of the locked 
tsk S2 resumes the execution of the critical section. 



task S2 unlocks S. 



tn 



tl2 



ti3 



ti 4 



The task S2 executes a service. 



The task S2 locks S. 



The task S2 unlocks R and therefore has as priority the same as S. The task Ri becomes 
having the highest priority. As it has more priority than S2, it resumes its execution. 



The task Ri locks R. 



The task Ri executes the reconfiguration. 



The task Ri unlocks R. 



The task Ri terminates its execution. 



The task S2 unlocks S (thus S2 becomes having the lowest priority). Therefore, the task Si 
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ti5 



ti6 



try 



ti8 



ti 9 



t20 



t21 



t22 



t23 



resumes its execution. 



The task Si locks S. 



The task Si locks R. 



The task Si unlocks S. 



The task Si executes its service. 



The task Si locks S. 



The task Si unlocks R. 



The task Si unlocks S. 



The task Si achieves its execution. 



The task S2 resumes the execution and terminates its service 



Task 



R1 



S1 



S2 



Begin 
reconfiguration 


Execute End 
reconfiguration ^(R) reconfiguration 

















Begin 
seivice 



Begin 

seivice P(S} 



P|R) 



V(S) 


Execute 
service 


P|S| V(R) 


Wa 




■////, 





t1 E 



13 t4 



Critical section guarded by S 
Critical section guarded l>y R 





Execute End 
S) P(R) V(S) servjce P|S) V(R) V(S) seiv ite 



//// 




////, 




//// 




///// 









End 

seivice 



t12 t13 t14 t15 t16 t17 m t19 t30 t21 12? 123 time 



Figure 2. The piid^^zeiling protocol applied to three tasks Ri, Si and S2 

Lulation With The Cheddar Tool 



Cheddar, developed at 
brest.fr/ -singhoff/ ch1 
The tool provides a afml 



[V. 



Jiversity of Brest, is a free real-time scheduling tool ( http:/ /beru.univ- 
|It is used to check temporal properties on real-time systems or applications, 
ition engine and feasibility tests (Figure 3). 




Task 



# Name task 

# Priority 

# Period 

# Capacity 

# Deadline 

# Jitter 

# Offset 

# Start time 

# Blocking time 

# User parameters 







Processor 




Shared 
resource 


# Name 

# isPreemptive 

# Quntum 

# Scheduling type 

# time 




# Rosou rcc name 

# initial state 

# Protocol 





Figure 3. Cheddar Architecture 
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The use of Cheddar is very simple through its graphical interface. 



First of all, a processor must be defined via the Edit/Update processors. To do so, a name, a scheduler 
policy and the nature (it is preemptive or not) must be indicated. 



Secondly, a memory address is precised in the Edit /Update address spaces by specifying its name. 
Finally, all the tasks have to be defined in the Edit/Update tasks by indicating its characteristics. 



o 



Scheduling with Cheddar 

S Definition of the processor: We aim to simulate the Priority Ceiling Protocol with the CheddaSi^ol 
For that reason, we define a processor by giving him a name (Processori) , an«d ^yy^faig as 
scheduler "POSIX 1003.1b /Highest Priority First". We choose a preemptive schedinina^hich is 
RTEMS_PREEMPT (Figure 4). 
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We add also a space of addressing assocj 
processor to which it is associated. 






Figure 4. Definiti^m^a processor 

ith the processor by indicating its name and the 



S Definition of the tasks: It is necepmf^o define the tasks and their properties. There are 4 types of 
tasks, periodic, aperiodic, fish ol^aNametric. The kind of task which interest us here is periodic. 
Afterthat, it is necessary toTcfi\ose between policies SCHED_FIFO or SCHED_RR used for the 
scheduling of the samefcllt priority. In this case, we choose SCHED_FIFO. It is also necessary to 
define the priority of tne\taSk. The priorities varies from 1 to 255, highest being 255. Lastly, it is 
necessary to specira«rk, starting times, deadline, and the period. These parameters are all 
obligatorily. x^^^^ 

In our examialeQ^ei create three tasks (Ti, T2 and T3) having as priority respectively (1, 2 and 1) 




(Figure 5). 
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Figure 5. Definition of a task with Cheddar 
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S Definition of the resource: As we need semaphores, resources should be added. We indicate the 
name of the resource, his initial value, and the intervals during which a task wants to reach the 
resource. These intervals cannot be null, i.e. a semaphore cannot be taken then delivered 
immediately. It is also necessary to specify the resource sharing protocol. Under Cheddar, the 
protocols available were No Protocol, PIP, PCP or IPCP. 

In our example, we define a resource (resourcei) associated with the PCP. The task Ti needs to useV^X 
this resource during the interval [2,3] whereas the tasks T2 wants to use it during the interval P>5% 
(Figure 6). ^7*^ 
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Figure 6. Definiti 



The Figure 7 depicts an analysis of this test case b] 
scheduling. The worst case response time compj 
in the bottom part of the window. 
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ir. The top part of the window shows the thread 
om this scheduling and with feasibility tests are shown 
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Figure 7. Scheduling with the Cheddar tool 

V. Conclusion 



This paper has as objective the study of Real-Time Task for Embedded Control System. We use the priority 
ceiling protocol as a method to ensure the scheduling between periodic tasks with precedence and mutual 
exclusion constraints. 
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The novelty of this paper is the study of dynamic reconfiguration with semaphore ensuring the following 
points: (i) blocking connections without blocking involved components; (ii) safety and correctness of the 
proposed solution; (iii) independence of any specific language; (iv) verification of consistency (i.e. logical 
constraints) ;(v) suitable for large-scale applications. 

In the future work, we will be interested in the problem of allocation of real-time tasks to the devices of the 
execution environment and the assignment of these instances to the operating systems. 
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